Codebook generation for cloud-based video applications

ABSTRACT

Techniques are disclosed for the improvement of vector quantization (VQ) codebook generation. The improved codebooks may be used for compression in cloud-based video applications. VQ achieves compression by vectorizing input video streams, matching those vectors to codebook vector entries, and replacing them with indexes of the matched codebook vectors along with residual vectors to represent the difference between the input stream vector and the codebook vector. The combination of index and residual is generally smaller than the input stream vector which they collectively encode, thus providing compression. The improved codebook may be generated from training video streams by grouping together similar types of data (e.g., image data, motion data, control data) from the video stream to generate longer vectors having higher dimensions and greater structure. This improves the ability of VQ to remove redundancy and thus increase compression efficiency. Storage space is thus reduced and video transmission may be faster.

REFERENCE TO PRIOR APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/055,913 (filed 29 Feb. 2016), the entire disclosure of which ishereby incorporated by reference herein.

FIELD OF THE DISCLOSURE

This disclosure relates to techniques for video processing, and moreparticularly, to techniques for generating codebooks to carry outimproved coding of compressed video content.

BACKGROUND

In general, data compression reduces the size of a digital file. Acompression algorithm typically makes the digital file smaller byrepresenting strings of bits (i.e., logical 1 s and 0 s), which make upthe digital file, with smaller strings of bits. For example, in somesystems, this may be accomplished by using a dictionary, or so-calledcodebook. This reduction typically happens at the encoding stage priorto transmission or storage. So, when such a reduced-size string isreceived at the decoding stage for playback, the decoding algorithm usesthe codebook to reconstruct the original content from the compressedrepresentation generated by the encoding algorithm. Whether thereconstructed content is an exact match of the original content or anapproximation thereof depends on the type of compression employed.Lossless compression algorithms allow the original content to bereconstructed exactly from the compressed message, while lossycompression algorithms only allow for an approximation of the originalmessage to be reconstructed. Lossless compression algorithms aretypically used where data loss of original content is problematic (suchas the case with executable files, text files, and digital data fileswhere loss of even a single bit may actually change the meaning of thecontent). Lossy compression algorithms are typically used for images,audio, video, and other such digital files where a degree of intentionaldata loss is imperceptible or otherwise at an acceptable level. Withrespect to lossy compression, note that the bit loss is not random;rather, the loss is purposeful (bits representing imperceptible sound orvisual distinctions or noise can be targeted for exclusion by the lossycompression algorithm).

Data compression is commonly used in applications where the storagespace or bandwidth of a transmission path is constrained. For example,images and video transmitted via a communication network such as theInternet are typically compressed. One such example case is theso-called “cloud DVR” service, which allows for streaming of compresseddigital video content from a remote digital video recorder to a user'splayback device, such as a television, desktop or laptop computer,tablet, smartphone, or other such playback device. Numerous compressionschemes are available for streamed video including, for example, thevarious MPEG compression algorithms, as well as codebook-based VectorQuantization (VQ) techniques.

Codebook-based vector quantization generally begins with vectorizationof a video stream by breaking the stream into smaller chunks of 1 s and0 s (i.e., vectors) and then comparing each input vector to vectors of agiven codebook to find a closest match. The index of the entry in thecodebook providing the closest match to the input vector can then beused to represent that input vector. Additionally, a residual vector maybe generated which represents a mathematical difference between thegiven input vector and the most similar codebook vector. The residualvector, paired with the codebook index, allows for lossless compression.Once coded, the content can be more efficiently stored and transmitted(i.e., use less storage space and transmission bandwidth), since onlythe indexes and residuals are stored and transmitted rather than thelonger vectors.

For codebook-based compression schemes, such as VQ, the quality anddegree of compression achieved is, at least to some extent, dependent ofthe representativeness of the codebook with respect to the input contentto be compressed. To this end, codebooks used in such compressionschemes are typically trained across multiple videos or channels over aperiod of time. The channels are generally controlled by a given contentprovider. The so-trained codebooks can then be used for compressing newdata in those channels.

In any case, because the content is stored in the cloud-based DVR, theuser doesn't need to have the content maintained in a storage local tothe playback device. As will be further appreciated, because compressionmakes the given digital file smaller (i.e., fewer bits), that file canbe stored using less memory space and transmitted faster, relative tostoring and transmitting that file in its uncompressed state.

However, there are a number of non-trivial problems associated withcloud-based DVR services. One such problem is related to the legalrequirement that each user's recordings stored in the cloud DVR must bea distinct copy associated with that user only. In another words, eventhough multiple users have recorded the same program (some piece ofdigital content), the cloud DVR service provider is required to save asingle copy of that program for each of those users. Thus, astorage-conserving technique such as data deduplication, which avoidscontent storage redundancy by leveraging a common copy of content thatis accessible to all users by operation of a pointer-based system, isunacceptable where the one copy per user requirement applies. Thisrequirement of a single copy per user is based in copyright laws relatedto the right of an individual to legally record content for purpose oftime-shifting the personal viewing of that content. Thus, a contentservice provider that is tasked with providing the same content item tomultiple users may still be constrained from a storage perspective andmay particularly benefit from improved compression schemes.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a top level block diagram of an example video contentstreaming system configured in accordance with an embodiment of thepresent disclosure.

FIG. 2a illustrates a block diagram of an encoder configured inaccordance with an embodiment of the present disclosure.

FIG. 2b illustrates a block diagram of a decoder configured inaccordance with an embodiment of the present disclosure.

FIG. 3 illustrates an example codebook.

FIG. 4 illustrates a block diagram of a codebook generator configured inaccordance with an embodiment of the present disclosure.

FIG. 5 illustrates the partitioning of an MPEG-2 transport stream inaccordance with an embodiment of the present disclosure.

FIG. 6 illustrates the grouping of stream components for vectorgeneration in accordance with an embodiment of the present disclosure.

FIG. 7 illustrates a block diagram of a vectorizer configured inaccordance with an embodiment of the present disclosure.

FIG. 8 illustrates a block diagram of a reorderer configured inaccordance with an embodiment of the present disclosure.

FIG. 9 is a flowchart illustrating a method for codebook generation inaccordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

There are instances where it is desirable to apply multiple compressiontechniques to the digital content of a video stream in order to achievea required level of compression of the video stream. For example, MPEGcompression may be applied to the video stream as an initial operation,generating a pre-compressed video stream, followed by codebook-basedvector quantization (VQ) to provide additional compression. However,problems may arise when VQ compression is applied to a pre-compressedvideo stream. The pre-compression, whether based on MPEG or otherexisting techniques, typically employs an entropy coding operation inone of the final stages to improve compression efficiency. This entropycoding removes structure that would otherwise be present in the videostream data (e.g., coefficients, motion vectors, etc.). The subsequentVQ compression relies on the existence of such structure in the videostream data to achieve compression, by removing or otherwise exploitingcorrelations in the data that are associated with that structure. Thus,the compression efficiency of conventional VQ compression techniques maybe degraded when applied to pre-compressed video that has undergoneentropy coding.

Furthermore, conventional VQ compression employs a vector codebook whichserves as a type of dictionary configured to map vectors extracted fromthe input video stream to relatively smaller values to further the goalof compression. For example, a vector extracted from the input videostream may be matched to a closest vector in the codebook and thus theindex value of that closest vector may be used as a substitute for thevector itself. The index value in some cases may simply be thesequentially numbered entry of the closest matching vector in thecodebook, and will therefore typically be much smaller than the originalvector extracted from the input video stream. The VQ codebook isgenerally created through a training process in which vectors areextracted from training video streams that are representative, to atleast some degree, of the types of video streams for which VQcompression will be desired. The vectors extracted from the trainingvideo are then typically clustered into groups and a single vector ischosen from each group, as most representative of that group, forinclusion in the codebook. The degree of VQ compression depends,however, on the quality of the vectors in the codebook. In general,codebook vectors with greater length and structure provide bettermatches to the vectors extracted from the input video stream and enablegreater removal of redundancy, thus providing better compression.

To this end, and in accordance with an embodiment of the presentdisclosure, techniques for VQ compression are disclosed that address thechallenges presented by pre-compression of the input video stream. Inparticular, an entropy decoding operation is performed on thepre-compressed video stream to reverse the effects of the entropy codingstage of the pre-compression process and restore structure that may havebeen lost. In some embodiments, the entropy decoding may include, forexample, one of the following: Context Adaptive Arithmetic decoding,Context Adaptive Variable Length decoding or Huffman decoding.

Additionally, techniques are disclosed for the generation of improved VQcodebooks that provide codebook vectors of increased length andstructure to achieve greater compression efficiency. The increasedlength codebook vectors are formed by grouping together components, of acommon type, from each block of the video stream. These components mayinclude, for example, image data segments, motion data segments andcontrol data segments. In the case of an MPEG pre-compressed videostream, for example, the blocks are Macroblocks and the image datasegments are Discrete Cosine Transform (DCT) blocks associated with theMacroblock, the motion data segments are motion vectors associated withthe Macroblock and the control data segments are Macroblock flags and/orheaders. In such case, the DCT blocks may be grouped together to formone vector, the motion vectors may be grouped to form another vector,and the Macroblock flags/headers may be grouped to form yet anotherthird vector for the codebook, as will be explained in greater detailbelow.

System Architecture

FIG. 1 illustrates a top level block diagram of an example video contentstreaming system configured in accordance with an embodiment of thepresent disclosure. As can be seen, the system is implemented in aclient-server architecture, including a number of client nodes 102, 104,106 (user playback systems 170) communicatively coupled to a cloudservice/remote server 160 via a communication network 140. Such aclient-server embodiment may be suitable, for example, for use in thecontext of an online or cloud-based DVR service that allows a subscriberor other user (client) to record and store video content to a remote DVR(server) for subsequent playback at a time suitable to the user. In thisexample embodiment, the content provider 130 provides video content to amedia server computer system 180. The media server computer system 180is programmed or otherwise configured with a standard compressed videostream generator 120, an encoder 100 and a decoder 110, as will bedescribed in greater detail below. The compressed stream generator 120may be configured to provide a first level of compression, for exampleMPEG compression, prior to the application of codebook-based VQcompression by encoder 100.

The storage mediums or storage facilities in the example case depictedinclude storage for VQ codebooks 150 a, codebook indexes 150 b andresiduals 150 c. Although the storage mediums are shown as separate,they need not actually be separate. In still other embodiments, thestorage mediums may be implemented with a distributed database that isaccessible to the content provider's media server. Likewise, while onemedia server is shown, any number of media servers can be used toexecute the various functionalities provided herein. In a more generalsense, numerous cloud-based back-end configurations can be used toimplement typical content provider functionality, which can besupplemented with the compression techniques provided herein.

In some embodiments, the encoded media data may be decoded, on demandfrom the client, by decoder 110 in the media server computer 180 priorto transmission over network 140 to the client-based playback systems170 (e.g., client 102). In other example embodiments, the client-basedplayback system 170 may include decoder 110 (e.g., client 104), so thatthe encoded media data may be directly transmitted over network 140 totake advantage of the compression-based savings with respect tobandwidth and transmission time. In these embodiments, however, thecodebook would also need to be provided to the clients.

In operation, the content provider receives a request to record videocontent from a user via one of the client-based playback systems and thenetwork. The video content requested for recording may be, for example,a scheduled broadcast or an on-demand purchase. In any case, the contentprovider generates the compressed video stream using the streamgenerator and may then initiate streaming of the content according tothe scheduled broadcast or otherwise at the requested time. In oneexample case, the compressed video stream is an MPEG-compressed videostream, although any number of compression schemes suitable forstreaming video can be used.

In addition to this conventional streaming activity carried out by thecontent provider, the content provider further acts to process theuser's request to record a copy of the content on the user's cloud DVRor other dedicated storage space available for such user requests. Tothis end, the compressed video stream is processed through the encoder100 to generate media data for storage in the storage medium 150 (user'scloud DVR), according to an embodiment of the present disclosure. Theencoding process carried out by the encoder 100 can be implemented, forexample, using any of the variations provided herein as will beappreciated in light of this disclosure. The stored media data can beencoded as optimized residual vector data using codebook-based vectorquantization, wherein the codebooks are generated using techniquesprovided herein.

In response to a request for playback of video content stored in theuser's cloud DVR, the media server is further configured to decode theencoded optimized residual vector data back into the compressed videostream and transmit it to the user over the network. The decodingprocess carried out by the decoder 110 can be implemented, for example,using any of the variations provided herein as will be appreciated inlight of this disclosure. The decoder 110 may use the codebooks storedin codebook storage 150 a which may be updated periodically (e.g.,during off-hours).

In some embodiments, in response to a request for playback of videocontent stored in the user's cloud DVR, the media server may beconfigured to stream the encoded optimized residual vector data to theuser over the network. The decoder 110 at the user's playback system canthen be used to decode the encoded optimized residual vector data backinto the compressed video stream, and present that stream to the uservia a display. The decoder 110 may use copies of the codebooks stored incodebook storage 150 a which may be updated periodically (e.g., duringoff-hours) and transmitted from the server to the clients.

The user's client can be implemented with any suitable computing device(e.g., laptop, desktop, tablet, smartphone, etc.) or other playbacksystem (e.g., television and set-top box arrangement, monitor and gameconsole arrangement, etc.). The network may include, for instance, alocal area network (LAN) operatively coupled to the Internet, or a cablenetwork, or a satellite network, or any other communication network overwhich video content can be transmitted. The media server can beimplemented with one or more server computers configured to receive andprocess user requests and to provision content. The storage mediums canbe any suitable non-volatile storage.

FIG. 2a illustrates a block diagram of an encoder 100 configured inaccordance with an embodiment of the present disclosure. As can be seen,the encoder 100 includes a vectorizer 101, a vector quantization encoder103, a codebook 105, and a residual encoder 107. The vector quantization(VQ) encoder 103 includes a residual generator 103 a. Additionally, acodebook generator 202 is provided to generate codebook 105. At a highlevel, the encoder 100 is configured to receive a pre-compressed inputvideo stream (e.g., an MPEG compressed version of the video stream fromthe content provider 130) and to output media data 108 that generallyincludes encoded optimized residuals and corresponding codebook indexes.This output can be stored for multiple users, such that there is onedistinct copy of media data 108 per user. In some embodiments, only aportion of the media data 108 is subject to the one copy per userrequirement. For instance, in one such example case, only the codebookindex is stored multiple times (one distinct copy per user) and theoptimized residual is stored only once. Other variations of a one copyper user scheme that may be compliant with the relevant applicablestandards and legal requirements can be used as well. In addition, theencoder 100 may also provide metadata which can be stored as a singlecopy, along with the codebook 105, so that they are available fordecoding the optimized residuals prior to transmission or at theplayback node, as will be explained in turn. The metadata may identifyor otherwise include data that facilitates decoding of the encodedoptimized media. In one embodiment, for instance, the metadataidentifies the total number of dimensions in the un-optimized residualvector and the length of each non-zero dimension, along with other datauseful in the decoding process, such as the length of the correspondingcodebook index, the total length of the residual vector (including alldimensions, both zeros and non-zeros) and the codebook identifier(assuming there is more than one codebook).

Other embodiments may be configured differently but still provide asimilar functionality. For instance, in another embodiment, thevectorizer 101 may be integrated with the VQ-encoder 103. Likewise, theresidual encoder 107 may be integrated with the VQ-encoder 103. Thedegree of integration can vary from one embodiment to the next. Furthernote that, in some embodiments, encoding can take place on atransmitting (content provider) node and decoding can take place on thereceiving (playback) node, such that an encoded compressed video streamis transmitted. Alternatively, encoding and decoding may both take placeat the transmitting node, so that a normal (not encoded) compressedvideo stream is transmitted. Numerous variations will be apparent andthe present disclosure is not intended to be limited to any particularone.

The vectorizer 101 may be configured to break the input pre-compressedvideo stream into vectors that are suitable for matching to the vectorsin codebook 105. As such, the vectorizing process is similar to theprocess used to generate the codebook and will be described in greaterdetail below in connection with the codebook generation process 202 andFIG. 7. In one example embodiment, vectorizer 101 is configured toreceive an MPEG-compressed input video stream. As will be appreciated,MPEG compression is used herein in a generic fashion, and is intended toinclude all typical use cases, including those where the audio and videoof a given media file is compressed by one of the standards that theMoving Picture Experts Group (MPEG) has promulgated (such as MPEG-1,MPEG-2, or MPEG-4) and multiplexed using the MPEG-2 transport streamstandard. However, as will be further appreciated in light of thisdisclosure, any ISO (International Organization for Standardization) orITU (International Telecommunication Union) standard, or other suchstandards, can be used instead of MPEG and the stream may or may not bemultiplexed. So, in a more general sense, the vectorizer 101 can beconfigured to receive any type of pre-compressed video stream,regardless of the compression standard used.

The vectors generated by the vectorizer 101 are provided to theVQ-encoder 103, which carries out the vector quantization process onthose vectors. Vector quantization is a lossy compression scheme used toencode/decode MPEG video streams, and is generally implemented bymapping input vectors from a given multidimensional input space into asmaller dimensional subspace using a set of representative code vectorsmaintained as a codebook. Such a vector codebook can be trained toimprove its representativeness of the digital content being compressed,as will be explained below. Thus, by virtue of encoding values from amultidimensional vector space into a finite set of values of a discretesubspace of lower dimension, the vector quantization process carried outby the VQ-encoder 103 allows for a relatively large data set to befairly well represented by a smaller data set and hence compression isachieved. So, with further reference to FIG. 2a , the VQ-encoder 103identifies the closest representative codebook vector in the givencodebook 105 (by way of Euclidean norms of the vectors being compared,or other suitable vector comparison technique). The difference betweenthat selected codebook vector and the input vector (from vectorizer 101)is generated by the residual generator 103 a, and this difference isreferred to as a residual vector. The residual vector can then be storedor otherwise made available for subsequent processing. This subsequentprocess generally includes optimizing and entropy coding the residualvector to further increase compression, as will be explained in turn.Further note that the index of the corresponding representative codebookvector selected from codebook 105, used to generate that residualvector, can be stored as well. This will allow for retrieval of the samecodebook vector from the codebook 105, when decoding is carried out.

Once the residual vector for a given input vector is computed by theVC-encoder 103, that residual vector and corresponding codebook vectorindex are provided to the residual encoder 107, as shown in FIG. 2a .The residual encoder 107 can implement any number of entropy codingschemes, such as Context Adaptive Arithmetic coding, Context AdaptiveVariable Length coding and Huffman coding, to compress the residualvectors. The reference to entropy refers to the notion that the residualvectors tend to have lower entropy than the original vectors received inthe vectorized compressed video stream (from vectorizer 101), becauselogical 0 s and low value dimensions tend to have high probabilities andhigh dimension values tend to have low probabilities.

A zero removal process by the residual encoder 107 provides an optimizedresidual vector. So, for instance, given a residual vector of {4 1 0 0 05 0 0 1 −2 0} from VQ-encoder 103, the optimized version of thatresidual vector would be {4 1 5 1 −2}. Because metadata may be storedand made available to the decoding process, the entropy coding schemecan be optimized and the coding tables can be smaller. So, for instance,and continuing with the previous example residual vector of {4 1 0 0 0 50 0 1 −2 0}, the optimized version of that residual vector would be {4 15 1 −2}. Applying decimal-to-binary conversion, the resulting optimizedresidual would be {100 1 101 1 10}. The dimension signs and lengths canbe recorded into metadata. In some embodiments, this binary value {100 1101 1 10} can then be used as an index or key into a Huffman table tofind the corresponding Huffman code. Alternatively, each of the fivedimensions can be treated as five input symbols presented for standardArithmetic coding.

FIG. 2b illustrates a block diagram of a decoder 110 configured inaccordance with an embodiment of the present disclosure. As will beappreciated, the decoder 110 provides functionality that iscomplementary to the encoder 100, and to this end discussion withrespect to decoding is kept concise and the previous relevant discussionregarding the encoder 100 is equally applicable here. As can be seen inFIG. 2b , the decoder 110 includes a residual decoder 111 (complementaryto residual encoder 107), a vector quantization (VQ) decoder 113(complementary to VQ-encoder 103), codebook 105 (which is the same), anda reorderer 115 (complementary to vectorizer 101). The VQ-decoder 113includes a vector generator 113 a (complementary to residual generator103 a). Further note that the decoder 110 may actually be on the samenode as the encoder 100, such as in applications where the compressiontechniques provided herein are being used to improve storage efficiencyrather than transmission speed. However, in other embodiments, thedecoder 110 can be implemented at a receiving node remote to thetransmitting node, such that storage efficiency at the transmitting nodeas well as faster transmission speed from the transmitting node to thereceiving node may be achieved if so desired.

At a high level, the decoder 110 is configured to receive media data 108that generally includes encoded optimized residuals and correspondingcodebook indexes, and to output a compressed video stream suitable forplayback (after reversing the pre-compression, e.g., MPEG compression).The received media data 108 is for a specific user, such that there isone distinct copy of media data 108 per user. However, and as previouslyexplained, in some embodiments, only a portion of the media data 108 issubject to the one copy per user requirement (e.g., the codebook indexmay be stored multiple times, once per user, and the optimized residualis only stored once). The decoder 110 may also receive metadata which,as previously explained, can be stored as a single copy, along with thecodebook 105, so that it is available for decoding the optimizedresiduals. So, for instance, let's continue with the previous exampleoptimized residual of {100 1 101 1 10} that was generated by the encoder100, as previously explained. Using the metadata, the residual decoder111 decodes the encoded version of this optimized residual to {4 1 5 1−2} in accordance with the given entropy coding scheme (andbinary-to-decimal conversion, in this example case). In this case, themetadata could indicate the dimensions having a negative polarity. Alsoknown from the metadata, according to an embodiment, is the total numberof dimensions of the residual vector, as well as the length and locationof non-zero dimensions of the residual vector. Thus, with thisinformation in hand, the residual decoder 111 further decodes {4 1 5 1−2} to {4 1 0 0 0 5 0 0 1 −2 0}, which is the original residual vector.Once the corresponding codebook vector is retrieved using the givencodebook index, the vector generator 113 a of the VQ-decoder 113recovers the original vector (or a relatively close representation ofthat original vector) by adding the original residual vector to theretrieved codebook vector. The recovered vectors are provided by theVQ-decoder 113 to the reorderer 115 which operates to re-combine thevectors to form the original pre-compressed video stream (or arelatively close representation thereof). The operations of thereorderer 115 will be described in greater detail below in connectionwith FIG. 8. In one example embodiment, reorderer 115 is configured toreceive a stream of discrete vectors having a known length and tocombine those vectors into an MPEG-compressed video stream, althoughother compression standards can be used as well.

As will be further appreciated in light of this disclosure, the variousmodules and components of the encoder 100 and decoder 110, such as thevectorizer 101 and reorderer 115, VQ-encoder 103 and VQ-decoder 113,residual encoder 107 and residual decoder 111, and codebook generator202 can be implemented in software, such as a set of instructions (e.g.C, C++, object-oriented C, JavaScript, BASIC, etc.) encoded on one ormore non-transitory computer readable mediums (e.g., hard drive,solid-state storage, server, or other suitable physical memory), thatwhen executed by one or more processors, cause the various methodologiesprovided herein to be carried out. A computer program product mayinclude any number of such computer readable mediums, and may bedistributed in nature. For instance, functional modules of the encoder100 can be implemented on a cloud-based server or other suitablecomputing environment, and the functional modules of the decoder 110 canbe implemented on a client-based computing device or suitable playbackplatform (e.g., television, laptop, projection system, smartphone,tablet, desktop, etc.). In other embodiments, the components/modules maybe implemented with hardware, such as gate level logic (e.g., FPGAs) ora purpose-built semiconductor (e.g., ASICs), which may also bedistributed in some embodiments. Still other embodiments may beimplemented with one or more microcontrollers (distributed or not) eachhaving a number of input/output ports for receiving and outputting dataand a number embedded routines for carrying out the functionalitydescribed herein. Any suitable combination of hardware, software, andfirmware can be used.

FIG. 3 illustrates an example codebook 105. The codebook is generated bycodebook generator 202 from a training video stream, as will bedescribed below. In some embodiments, codebook 105 may be relativelystatic in nature, such that it is previously trained on a relevant setof content channels of the content provider 130 and then deployed foruse by the encoder 100 (and decoder 110). In other embodiments, thecodebook 105 may be more dynamic in nature where updating of thecodebook representative code vectors is an ongoing process usingadditional content channels for continued training. The example codebook105 is shown to include index values 302 and associated N vector entries304, each vector comprising a number of dimensions or elements. Notethat the size (and hence, resolution) of the codebook can vary greatlyfrom one embodiment to the next. In a general sense, the greater theresolution of the codebook 105 (i.e., the higher the number of distinctindexed codebook vectors, N), the greater the representativeness of thetargeted multidimensional space (video content library of serviceprovider) being subjected to vector quantization. The greater therepresentativeness of the targeted multidimensional space, the smallerin value the residual vectors will be. Said differently, the morerepresentative a given codebook vector is of a given input vector, thelower the number of non-zero dimensions or elements are in the resultingresidual vector. The lower the number of non-zero dimensions in theresulting residual vector, the fewer the number of bits required tostore it (e.g., zero removal) and thus the greater the degree ofcompression that can be applied to that residual. Zero removal may alsotypically improve entropy coding efficiency.

FIG. 4 illustrates a block diagram of the codebook generator 202, fromFIG. 2a above, configured in accordance with an embodiment of thepresent disclosure. The codebook generator 202 is shown to include anentropy decoder 402, a Macroblock partitioner 404, a grouping module406, a vector generator 410, a codebook selector 408, and a vectorclustering module 412. Taken together, these various modules providetechniques for codebook generation based on pre-compressed trainingvideo streams. The techniques include the formation of relatively longercodebook vectors by grouping together components, of a common type, foreach block of the pre-compressed training video streams, as will beexplained in greater detail below. The resulting longer vectors havehigher dimensions and greater structure which improve the ability ofvector quantization to remove redundancy and thus increase compressionefficiency.

The training video streams may be provided by content provider 130, orany other suitable source, with compression (e.g., MPEG compression)applied by compressed stream generator 120 in a manner similar to thatof the pre-compressed input video stream, provided to vectorizer 101, asdescribed above. The training video stream or streams include digitalcontent that is representative of what will be provided in thepre-compressed input video stream, so that the resulting codebook willbe representative of the input vectors generated by vectorizer 101 fromthe pre-compressed input stream. The more representative the codebook isof the input vectors, the smaller in magnitude the residual vectors willtend to be, potentially requiring fewer bits to represent those vectorsand thus improving compression efficiency.

The entropy decoder 402 may be configured to perform entropy decoding onthe pre-compressed training video stream to provide a decoded videostream for codebook generation. In other words, the entropy decoderreverses the effect of the final entropy coding stage of the preliminarycompression (e.g., MPEG compression) that may be applied by compressedstream generator 120 on the training video stream, in the same mannerthat such preliminary compression is performed on the input videostream.

Reversal of the entropy coding restores the structure and correlationthat was originally present in the data (e.g., quantized coefficientsand motion vectors of an MPEG compressed stream) prior to entropycoding. This results in a codebook that may provide improved hits ormatches between the vectors generated from the input video stream (byvectorizer 101) and the vectors in the codebook. Closer matches mayresult in smaller residuals requiring fewer bits and thus better VQcompression. In some embodiments, the entropy decoding may include, forexample, one of the following: Context Adaptive Arithmetic decoding,Context Adaptive Variable Length decoding, Huffman decoding or any othersuitable decoding scheme.

The Macroblock partitioner 404 may be configured to partition thedecoded video stream into image data segments, motion data segments andcontrol data segments. In one such embodiment, for example where thetraining video stream is an MPEG-compressed video stream, the image datasegments may be Discrete Cosine Transform (DCT) blocks associated with aMacroblock, the motion data segments may be motion vectors associatedwith the Macroblock, and the control data segments may be Macroblockflags or headers or other relevant information. This is illustrated ingreater detail, for example in FIG. 5, which shows how an MPEG-2transport stream 502 is hierarchically organized into levels.

Referring to FIG. 5, at the top level the transport stream isdemultiplexed into headers 504, video 506 and audio 508. The video inturn may be further parsed into slices 510 and associated headers 512.Each slice 510 may be further partitioned into one or more Macroblocksthat include headers/flags and other control data 514, DCT blocks 516and motion vectors 518. The DCT blocks 516 may come in different sizes,for example 4×4 blocks 520, 8×8 blocks 522 and other sizes 524,including DC or 1×1 values. The DCT blocks generally encode informationdescribing a color image at a particular point in time while the motionvectors generally encode a prediction of how the image will move fromone point in time to another.

The grouping module 406 and vector generator 410 may be configured togroup the partitioned segments of each type (typically within a singlemacroblock) together to form vectors. For example, the image datasegments (DCT blocks) are grouped to form a first vector, the motiondata segments (motion vectors) are grouped to form a second vector, andthe control data segments (Macroblock flags/headers) are grouped to forma third vector. Thus, the resulting first vector is longer than any oneof the image data segments from which it is formed. Similarly, theresulting second vector is longer than any one of the motion datasegments from which it is formed and the resulting third vector islonger than any one of the control data segments from which it isformed. This is illustrated in greater detail, for example in FIG. 6,which shows how MPEG stream components may be grouped into vectors.

In FIG. 6, the partitioned Macroblock (MB) flags 514 a, 514 b, 514 c aregrouped to form a first vector 602. Similarly, the partitioned MB DCTblocks 516 a, . . . 516 n are grouped to form a second vector 604 andthe partitioned MB motion vectors 518 a, 518 b are grouped to form athird vector 606. In some embodiments, only contiguous fields in theMacroblock (e.g., x-axis motion vectors and y-axis motion vectors) aregrouped together to form larger vectors. All flag data from a singleMacroblock may generally be grouped together, however, to form a largervector, even when not contiguous (e.g., interleaved with other fields).

In some embodiments, different codebooks may be generated depending onthe type and size of the partitioned segments. For example, and withreference to MPEG streams, 8×8 DCT blocks may be mapped to one codebookwhile 4×4 DCT blocks may be mapped to a different codebook. Likewise,larger motion vectors and smaller motion vectors may be mapped todifferent codebooks. The codebook selector 408 may be configured todetermine which codebook a given vector will be mapped to, based on acomparison to a selected size threshold. The mapping to differentcodebooks may vary as the stream is being processed since DCT blocksizes and motion vector sizes may vary throughout the stream.

In some embodiments, vector generator 410 may be further configured todetermine the size of the data associated with each Macroblock, and, ifthe size is less than a selected threshold size, form a single vectorfrom the combination of the DCT blocks, motion vectors and flags of thatMacroblock. The application of a size threshold may avoid thecombination of different types of vectors which might not yield the bestresults if combined in a single codebook. In other words, if theMacroblock is smaller than the threshold size, the decoded values of theentire Macroblock are used as the dimensions or elements of a singlecodebook vector. This may provide improved vector quantization whereMacroblock components (e.g., DCT blocks and motion vectors) are in therange of approximately 8 bits or less.

The size of the generated codebook 105 is typically limited by a desireto maintain the length of the indexes to a relatively small value toconserve space since these indexes are stored or transmitted as part ofthe VQ compressed stream. In some embodiments, indexes may be limited toa range of approximately 7 to 10 bits allowing for a codebook size inthe range of 128 to 1024 entries, although other ranges are, of course,possible depending on the application and other constraints.

However, in some embodiments/instances, the total number of vectors thatmay be generated from a training video stream or streams may be two tothree orders of magnitude greater than the codebook can accommodate.Vector clustering module 412 may be configured to select the mostrepresentative vectors from all available vectors for inclusion in thecodebook. A clustering algorithm may be used to group the availablevectors into clusters or segments and find the centroid of thoseclusters to serve as a representative vector. The clustering algorithmand centroid determination may be implemented using known techniques inlight of the present disclosure. Vector clustering module 412 mayfurther be configured to enter each selected or representative vector asan entry into the codebook along with an associated index value, asillustrated in FIG. 3.

FIG. 7 illustrates a block diagram of a vectorizer 101 configured inaccordance with an embodiment of the present disclosure. The vectorizer101, as previously described, may be configured to break the inputpre-compressed video stream (e.g., an MPEG stream) into vectors that aresuitable for matching to the vectors in codebook 105, which weregenerated by the techniques described herein. As such, the vectorizingprocess 101 applied to the input pre-compressed video stream issubstantially similar to the process used to generate the codebookvectors from the training pre-compressed video stream. In particular,vectorizer 101 is shown to include the entropy decoder 402, Macroblockpartitioner 404, grouping module 406, vector generator 410 and acodebook selector 408, all of which may operate in a substantiallyidentical manner to the corresponding components/modules of the codebookgenerator 202 illustrated in FIG. 4. The vector clustering and codebookindexing operations 412 of the codebook generator 202 are not, however,included in vectorizer 101 as the vectorizer is configured to generatevectors to be used to find closest matches to codebook entries ratherthan for the purpose of generating entries for the codebook.

FIG. 8 illustrates a block diagram of a reorderer 115 configured inaccordance with an embodiment of the present disclosure. The reorderer115, as previously described, may be configured to re-combine the VQdecoded vectors to form the original pre-compressed video stream (or arelatively close representation thereof). In particular, the reorderer115 is shown to include a flag extraction module 802, a DCT and MVextraction module 804, a reordering module 806 and an entropy encoder808, which operate together to essentially reverse the operations ofvectorizer 101.

The flag extraction module 802 may be configured to extract control datasegments (e.g., Macroblock flags, headers, etc.) from the vector. Theseflags may then be used to locate the remaining components or fields ofthe Macroblock. In some embodiments, metadata (e.g., providing thelengths and locations of these fields) may also be provided to assistwith this operation. DCT and MV extraction module 804 may be configuredto extract the image data segments (e.g., DCT blocks) and motion datasegments (e.g., motion vectors) from the vectors, based at least in parton the previously extracted flag data and other header/controlinformation.

Reordering module 806 may be configured to reorder the extractedcomponents (e.g., flags, DCT blocks, motion vectors) back into theoriginal ordering of the pre-compressed video stream. In other words,reordering module 806 reverses the operations of Macroblock partitioner404 and grouping module 406. Flag data (and possibly metadata) may beused to determine the original ordering of the components.

Entropy encoder 808 may be configured to restore the entropy encodingthat was previously removed by entropy decoder 402 during the VQcompression process as described earlier.

Methodology

FIG. 9 is a flowchart illustrating a method for improved VQ codebookgeneration in accordance with an embodiment of the present disclosure.As can be seen, the method is described with reference to theconfiguration of codebook generator 202 of FIG. 4. However, any numberof codebook generator configurations can be used to implement themethod, as will be appreciated in light of this disclosure. Further notethat the various functions depicted in the method do not need to beassigned to the specific example modules shown. To this end, the examplemethodology depicted is provided to give one example embodiment and isnot intended to limit the methodology to any particular physical orstructural configuration.

The method commences at 910 with entropy decoding performed on thepre-compressed training video stream to restore structure to the datathat may have been lost during a previous entropy coding operation. Thisoperation may be performed by entropy decoder 402. In one example case,the pre-compressed training video stream is an MPEG-compressed videostream, although any suitable compression standard can be used thatproduces a pre-compressed video stream that can be vectorized, forexample a stream that is block based or comprises groupings of pixels.The method continues at 920 with partitioning of the decoded videostream into various segments such as, for example, image data segments,motion data segments, and control data segments. In one such embodiment,for example where the training video stream is an MPEG-compressed videostream, the image data segments may be Discrete Cosine Transform (DCT)blocks associated with a Macroblock, the motion data segments may bemotion vectors associated with the Macroblock and the control datasegments may be Macroblock flags or headers or other relevantinformation. This operation may be performed by Macroblock partitioner404.

Next, at operation 930, the image data segments are grouped to form afirst vector, the motion data segments are grouped to form a secondvector and the control data segments are grouped to form a third vector.At operation 940, one or more codebook entries, associated with indexvalues, are generated based on these vectors. The index values provide acompressed representation of the entries, as previously described. Notethat in some embodiments, different codebook may be generated dependingon the size of the partitioned segments. For example, and with referenceto MPEG streams, 8×8 DCT blocks may be mapped to one codebook while 4×4DCT blocks may be mapped to a different codebook. The mapping todifferent codebooks may occur dynamically as the stream is beingprocessed since DCT block sizes and motion vector sizes may varydynamically throughout the stream.

Note that the entropy decoding performed at operation 910, to restore orimprove data structure in the stream, may result in a morerepresentative codebook that reduces or otherwise minimizes thedistortion post-VQ (i.e., the residual vector values). In other words, acodebook may be considered “representative” when the accuracy of thecodebook is such that the given codebook vectors tend to be not muchdifferent from the given input vectors being subjected to VQ, which inturn yields residual vectors that tend to be smaller in value. In such ascenario, a greater number of the elements (or dimensions) making up agiven residual vector tend to be zero with the remainder of thedimensions tending to be a low number. However, there may still beoccasional high error magnitudes (i.e., codebooks are generally notperfect, regardless of how well trained they are).

Of course, in some embodiments, additional operations may be performed.For example, if the size of the Macroblock data is less than a selectedthreshold value, a single vector may be formed by grouping the DCTblocks, the motion vectors and flags into one indexed codebook vectorentry. Additionally, due to constraints on the size of the codebook(i.e., total number of entries) a clustering algorithm may be used toreduce the total number of generated vectors by selecting and retaininga subset of the vectors that are most representative, by some suitablemeasure, of the pre-compressed training video stream.

Example Embodiments

Numerous example embodiments will be apparent, and features describedherein can be combined in any number of configurations.

Example 1 includes a method for generating codebooks for vectorquantization of digital video content. The method includes: performingentropy decoding on a pre-compressed training video stream to provide adecoded video stream, wherein the pre-compressed training video streamincludes entropy coding; partitioning the decoded video stream intosegments, the segments including image data segments, motion datasegments, and control data segments; grouping the image data segments toform a first vector, wherein the first vector is longer than any one ofthe image data segments; grouping the motion data segments to form asecond vector, wherein the second vector is longer than any one of themotion data segments; grouping the control data segments to form a thirdvector, wherein the third vector is longer than any one of the controldata segments; generating entries in at least one codebook of thecodebooks, the entries based on at least one of the first vector, thesecond vector, and the third vector; and associating an index value witheach of the entries, wherein the index value is shorter than the entriessuch that the index value provides a compressed representation of theentries.

Example 2 includes the subject matter of Example 1, wherein the entropydecoding of the pre-compressed training video stream includes at leastone of Context Adaptive Arithmetic decoding, Context Adaptive VariableLength decoding and Huffman decoding.

Example 3 includes the subject matter of Example 1 or 2, wherein thepre-compressed training video stream is an MPEG-compressed video stream.

Example 4 includes the subject matter of any of the previous Examples,wherein the image data segments are Discrete Cosine Transform (DCT)blocks associated with a Macroblock, the motion data segments are motionvectors associated with the Macroblock and the control data segments areMacroblock flags.

Example 5 includes the subject matter of any of the previous Examples,further comprising generating a plurality of codebooks, wherein each ofthe codebooks is to store vectors associated with DCT blocks and motionvectors of a selected size.

Example 6 includes the subject matter of any of the previous Examplesfurther comprising: determining a size of the Macroblock data; if thesize of the Macroblock data is less than a selected threshold size,forming a single vector from the DCT blocks, the motion vectors and theMacroblock flags; and generating an indexed entry in one or more of thecodebooks based on the single vector.

Example 7 includes the subject matter of any of the previous Examples,further comprising reducing the number of entries in the codebook byapplying a clustering algorithm to the vectors to select and retainvectors that are most representative of the pre-compressed trainingvideo stream.

Example 8 includes a computer program product comprising one or morenon-transitory computer readable mediums encoded with instructions thatwhen executed by one or more processors cause a process to be carriedout for generating codebooks for vector quantization of digital videocontent, the process comprising the method of any of Examples 1 through7.

Example 9 includes a system for generating codebooks for vectorquantization of digital video content, the system comprising: a storagefacility; and one or more processors configured to: perform entropydecoding on a pre-compressed training video stream to provide a decodedvideo stream, wherein the pre-compressed training video stream is anMPEG-compressed video stream including entropy coding; partition thedecoded video stream into segments, the segments including image datasegments, motion data segments, and control data segments; group theimage data segments to form a first vector, wherein the first vector islonger than any one of the image data segments; group the motion datasegments to form a second vector, wherein the second vector is longerthan any one of the motion data segments; group the control datasegments to form a third vector, wherein the third vector is longer thanany one of the control data segments; generate entries in at least onecodebook of the codebooks, the entries based on at least one of thefirst vector, the second vector, and the third vector; and associate anindex value with each of the entries, wherein the index value is shorterthan the entries such that the index value provides a compressedrepresentation of the entries.

Example 10 includes the subject matter of Example 9, wherein the one ormore processors are further configured to entropy decode thepre-compressed training video stream by using at least one of ContextAdaptive Arithmetic decoding, Context Adaptive Variable Length decodingand Huffman decoding.

Example 11 includes the subject matter of Example 9 or 10, wherein thegrouping of the partitioned segments is a grouping of contiguous fieldsof a Macroblock.

Example 12 includes the subject matter of any of the previous Examples,wherein the image data segments are Discrete Cosine Transform (DCT)blocks associated with a Macroblock, the motion data segments are motionvectors associated with the Macroblock and the control data segments areMacroblock flags.

Example 13 includes the subject matter of any of the previous Examples,wherein the one or more processors are further configured to generate aplurality of codebooks, wherein each of the codebooks is to storevectors associated with DCT blocks and motion vectors of a selectedsize.

Example 14 includes the subject matter of any of the previous Examples,wherein the one or more processors are further configured to: determinea size of the Macroblock data; if the size of the Macroblock data isless than a selected threshold size, form a single vector from the DCTblocks, the motion vectors and the Macroblock flags; and generate anindexed entry in one or more of the codebooks based on the singlevector.

Example 15 includes the subject matter of any of the previous Examples,wherein the one or more processors are further configured to reduce thenumber of entries in the codebook by applying a clustering algorithm tothe vectors to select and retain vectors that are most representative ofthe pre-compressed training video stream.

The foregoing description of example embodiments of the disclosure hasbeen presented for the purposes of illustration and description. It isnot intended to be exhaustive or to limit the disclosure to the preciseforms disclosed. Many modifications and variations are possible in lightof this disclosure. It is intended that the scope of the disclosure belimited not by this detailed description, but rather by the claimsappended hereto.

What is claimed is:
 1. A method for generating a codebook for vectorquantization of digital video content, the method comprising: performingentropy decoding on a pre-compressed training video stream to provide adecoded video stream; partitioning the decoded video stream intosegments, the segments including a subset of image data segments;grouping the subset of image data segments to form an image data vectorthat is longer than each of the image data segments in the subset;generating a codebook entry that is at least partially based on theimage data vector; and associating an index value with the generatedcodebook entry, wherein the index value is shorter than, and provides acompressed representation of, the generated codebook entry.
 2. Themethod of claim 1, further comprising: selecting a codebook based on adimensional size of the image data segments in the subset; and mappingthe generated codebook entry to the selected codebook.
 3. The method ofclaim 1, wherein the image data segments in the subset are DiscreteCosine Transform blocks associated with a macroblock that forms part ofthe pre-compressed training video stream.
 4. The method of claim 1,wherein the image data segments in the subset are Discrete CosineTransform blocks having a common dimensional size.
 5. The method ofclaim 1, wherein the image data vector includes image data segments froma single macroblock that forms part of the pre-compressed training videostream.
 6. The method of claim 1, wherein: the pre-compressed trainingvideo stream has been subjected to an MPEG compression technique; andperforming entropy decoding restores a structure and correlation thatwas present in the pre-compressed training video stream before beingsubjected to the MPEG compression technique.
 7. The method of claim 1,wherein performing entropy decoding causes quantized coefficients andmotion vectors to be extracted from the pre-compressed training videostream.
 8. The method of claim 1, wherein entropy decoding thepre-compressed training video stream involves at least one of ContextAdaptive Arithmetic decoding, Context Adaptive Variable Length decoding,and Huffman decoding.
 9. The method of claim 1, wherein the segmentsfurther include a subset of motion data segments and a subset of controldata segments.
 10. A computer program product comprising one or morenon-transitory computer readable media encoded with instructions that,when executed by one or more processors, cause a process for encodingpre-compressed digital video content using vector quantization, theprocess comprising: performing entropy decoding of a pre-compressedvideo stream to provide a decoded video stream; partitioning the decodedvideo stream into segments, the segments including a subset of imagedata segments; grouping the subset of image data segments to form acomposite image data vector that is longer than each of the image datasegments in the subset; matching the composite image data vector with anidentified image data vector that is stored in a codebook; andextracting, from the codebook, an index value that is associated withthe identified image data vector.
 11. The computer program product ofclaim 10, wherein the image data segments in the subset are DiscreteCosine Transform blocks associated with a macroblock that forms part ofthe pre-compressed video stream.
 12. The computer program product ofclaim 10, wherein the segments further include a subset of motion datasegments and a subset of control data segments.
 13. The computer programproduct of claim 10, wherein the pre-compressed video stream is anMPEG-compressed video stream.
 14. The computer program product of claim10, wherein entropy decoding the pre-compressed video stream comprisesat least one of Context Adaptive Arithmetic decoding, Context AdaptiveVariable Length decoding, and Huffman decoding.
 15. The computer programproduct of claim 10, wherein the identified image data vector is aclosest match with the composite image data vector, from amongst aplurality of image data vectors stored in the codebook.
 16. The computerprogram product of claim 10, wherein the subset of image data segmentswhich are grouped to form the composite image data vector is a groupingof contiguous fields of a macroblock that forms part of thepre-compressed video stream.
 17. A system for decoding a video streamthat has been encoded using vector quantization, thereby producing acompressed video stream, the system comprising a memory and one or moreprocessors configured to: receive a plurality of codebook indexes and aplurality of residual vectors; use a codebook to generate a first vectorcomprising a plurality of image data segments, a second vectorcomprising a plurality of motion data segments, and a third vectorcomprising a plurality of control data segments, wherein the first,second and third vectors are generated based on the codebook indexes andresidual vectors; extract the control data segments from the thirdvector; use the control data segments to extract the image data segmentsfrom the first vector and to extract the motion data segments from thesecond vector; and reorder the control data segments, the image datasegments, and the motion data segments to generate the compressed videostream.
 18. The system of claim 17, wherein the motion data segmentsthat comprise the second vector represent contiguous fields of amacroblock.
 19. The system of claim 17, wherein the image data segmentsare Discrete Cosine Transform blocks having a common dimensional size.20. The system of claim 17, wherein: the plurality of image datasegments include Discrete Cosine Transform blocks associated with amacroblock that forms part of the compressed video stream; the pluralityof motion data segments include motion vectors associated with themacroblock; and the plurality of control data segments includemacroblock flags.